1. Field of the Invention
The present invention relates generally to management software, and, more particularly, relates to converting legacy or proprietary management software into software compatible with new industry-standard architecture.
2. Description of Prior Art
To say that growth of the computer industry has been rapid is something of an understatement. Computer companies develop and market (1) hardware such as mainframes, personal computers, peripherals including storage systems, printers, terminals and modems; (2) software which runs on and controls that hardware such as operating systems software and applications software such as peripheral-device management software; and, (3) networking infrastructure, such as the Internet, employing this hardware and software. As noticed by many, this industry is a powerful engine pulling civilization forward in an almost uncomfortably rapid manner.
Because of constant, intense and competitive technological design enhancement activity inherent in this industry, different, and frequently incompatible, technical designs are created. Such incompatibility can result in difficult situations, as, for example, where a corporate user of this technology utilizes, for example, different storage systems each having architecture incompatible with the others, internal to its own organization. In this circumstance, each storage system vendor has produced its own proprietary or “legacy” architecture and supplied same to this corporate-customer user who now has the challenge of managing or handling such incompatibility in as efficient and graceful a manner as possible. Regrettably, one storage system management software package cannot readily communicate with a different vendor's storage system management software package within the same corporate environment, without arduous code generation to close the communication gap! Thus, this corporate user, unfortunately, is now burdened with meeting this challenge including the taking of redundant actions. Such actions are, for example, providing multiple training sessions to its employees, so they can describe and handle failures, degradations and other complications which may arise in these incompatible storage systems, in as many different languages as are dictated by such different legacy or proprietary architectures defining such systems. This confusing and inefficient scenario results from an availability of too many different kinds of management tools and places an unwanted drain on this corporate user's resources. Accordingly, computer industry vendors have created standards committees and organizations in which their companies can be represented, for purposes of interacting and generating standards of design for the good of all concerned, including corporate-customer users as exemplified above.
Thus, one technical area where need for standardization is apparent is in the computer storage-system management arena where certain storage-management software products are based on older, less-desirable, or increasingly-incompatible legacy or proprietary architectures. These architectures are combinations of software such as schemas, languages and protocols, etc. For example, referring to FIG. 2A, one such legacy architecture hierarchy is depicted: at the bottom of the architecture stack are protocols: TCP/IP (Transmission Control Protocol/Internet Protocol), Sockets, and Rogue Wave (Net.H++). On top of those protocols, in this example, is object-oriented computer language C++. And on top of that computer language is a schema (header-related software and further defined hereinbelow) such as that derived from or implemented in RAID++. RAID++ is an object-oriented representation of a CLARiiON® storage system (registered trademark of assignee) in C++ language, and objects are defined below.
Legacy architecture such as that comprising TCP/IP, Sockets, Rogue Wave and schemas is fundamental to the design of networks such as, for example, a client-server network. In a client-server network, several communication aspects need to be specified: (1) How does the client communicate with the server? TCP/IP over an ethernet cable would be responsive to this question. (2) What language will be used by the client and server? Rogue Wave and Sockets are among the answers responsive to this question. (3) What language is the code written in? C++ or JAVA would be examples of languages responsive to this question. (4) What subject will be talked about? Schema would focus the subject to particular subject matter such as, for example, “storage management” as opposed to, for example, “extracting banking information”. Thus, legacy architecture defines the client-server network.
Although legacy or proprietary architectures can still be useful under certain circumstances, they are generally no longer the architecture of choice for reasons of incompatibility noted above and for other reasons. For example, it is not unusual for legacy or proprietary architecture to employ C++ language. Such language is typically represented in object “trees” because C++ fits naturally with tree representation, (although C++ can also be represented otherwise). Tree representations have certain analytical-design disadvantages as compared with a flat object representation. Objects, object trees, and an improved “flat” object database representation, all in connection with industry standardization, are described as follows. One industry standardization effort is being conducted by the Distributed Management Task Force, Inc. (DMTF) and is moving in a direction entitled: “Web-Based Enterprise Management” (WBEM). One area being addressed by this effort is within the aforementioned software category known as “object-oriented” software. An object, in computer software terms, is a dedicated area of memory which can be thought of as an impervious container holding both data and instructions within itself, both defining itself and its relationships to other objects in the computer system or network. An object can send and receive messages to and from other objects, respond and react to such messages (e.g. commands) but shall normally be impervious to internal scrutiny. For example, in a storage processor (a kind of computer) each object may describe or relate to a specific detail in the processor (e.g. a fan, power switch, cache memory, power supply, disk drive interface, etc.), where these tangible objects in the storage processor can send messages to each other and to other objects outside the processor.
If operating with C++ computer language, as noted above, the relationship between these specific objects in the storage processor is usually visualized or characterized as a “tree” of objects. In a tree, each such object hangs off a preceding object as if in a parent-child or inheritance relationship, with many children hanging from a parent not being an a typical configuration. In addition to these tangible kinds of objects, logical units (LUNs) are other nodes or objects that can be contained within the tree. If a user wants to know, for example, about all existing LUNs (and there can be a vast number) in a particular tree configuration, any hardware/software search solution for them is necessarily based on a design which must, in turn, be based on such tree representation. Thus, a search through the entire tree must be conducted to find all LUNs, which can be a cumbersome and time consuming task under certain conditions. Furthermore, even if not searching for LUNs, in order for a search or message transfer to proceed in the tree from one node or object to another, again the entire tree may have to be navigated. When there are thousands or more of these objects in the tree, this could take too much time as a message passes from object to object within the tree. Accordingly, for these and other reasons not relating to performance WBEM is establishing a standard that avoids object trees and arranges all objects in a database where a “flat” relationship is obtained, i.e., objects can communicate from one to the other directly and need not proceed through intermediary objects as required in the tree configuration. Flat-database-represented eXtensive Markup Language (XML) has been selected by WBEM.
XML, in addition to allowing a flat object database where one object can communicate directly with any other object in the database, is a language that offers other advantages with respect to Internet usage. XML is related to or is a superset of Hypertext Markup Language (HTML), and Internet browsers display information in HTML. XML thus enables companies to leverage Web technologies to manage enterprise systems such as storage systems. Therefore, XML is a language of choice in view of its Internet compatibility.
Referring to FIG. 2B, a new architecture stack is shown and is to be compared with the legacy architecture stack of FIG. 2A. In FIG. 2B, the earlier-noted TCP/IP protocol is still at the bottom followed by the aforementioned HTTP protocol, on top of which is the aforementioned XML computer language; and, on top of XML is a new and advantageous schema called Common Information Model (CIM). (A schema can be viewed as a description of a class structure, i.e., the schema enumerates all the classes, how they are related to each other in terms of reference to each other and in terms of parent-child inheritance relationships, maybe including a description of all properties that these classes may have, and maybe further including all methods that can be executed in those classes.) A ninety-seven (97) page specification entitled “Common Information Model (CIM) Specification” Version 2.2, dated Jun. 14, 1999 prepared by the Distributed Management Task Force, Inc. (DMTF) offers more information about this subject and is incorporated by reference herein in its entirety. Another specification of eighty-seven (87) pages entitled “Specification for CIM Operations of HTTP” Version 1.0, dated Aug. 11, 1999, prepared by DMTF likewise provides valuable background information and is also incorporated by reference herein in its entirety. CIM is superior to older, legacy-based schemas in the one respect that it creates interoperability and allows management of different storage systems supplied by different vendors. CIM also has capability of modeling servers, software on servers, power supplies on servers, network switches, tape backup, and virtually all other manageable components in a computer system.
Serious potential effort and expense issues enter into this scenario when considering the huge legacy architecture which has been developed in this industry thus far. There has been major investment on the part of many industry participants (multiple-hundreds of industry vendors) in each of their own respective brands of proprietary or legacy architecture. Such architecture is not only the specific layered architecture shown in FIG. 2A useful with at least CLARiiON® storage systems (registered trademark of assignee), but any legacy architecture including that which is not in conformance with FIG. 2A and different from the proposed standard of FIG. 2B. As industry vendors know, to change one's investment from any legacy architecture, e.g. that represented by FIG. 2A to that of FIG. 2B, is a major undertaking typically requiring the writing of a huge number of lines of code. What is needed for the industry, therefore, for both industry vendors and users alike, is an automatic conversion technique to permit the large investment made by multiple industry participants, regardless of their specific legacy architecture, to be preserved and upgraded to the new standard stack of FIG. 2B, or to any other new standard, automatically and with minor impact on their respective businesses.
Embodiments of the present invention provide a welcome solution to the aforementioned prior art problems. Such embodiments are far easier to implement than the aforementioned line-by-line code upgrade conversion. Moreover, not only do such embodiments relate to and solve specific problems associated with the particular legacy architecture shown in FIG. 2A, but their underlying algorithms can also provide a solution to almost any legacy architecture upgrade challenge.